home *** CD-ROM | disk | FTP | other *** search
- Date: Fri, 26 Aug 94 04:30:20 PDT
- From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
- Errors-To: Ham-Digital-Errors@UCSD.Edu
- Reply-To: Ham-Digital@UCSD.Edu
- Precedence: Bulk
- Subject: Ham-Digital Digest V94 #285
- To: Ham-Digital
-
-
- Ham-Digital Digest Fri, 26 Aug 94 Volume 94 : Issue 285
-
- Today's Topics:
- HF -> internet gateways?
- HF Packet (Mac vs PC)
- HP100LX + Baycomm = Success?
- jnos trace question (2 msgs)
- jnos w/enet card
- mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies
- Packet Routing with JNOS 110f
- What SB for Digital modes?
-
- Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
- Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
- Problems you can't solve otherwise to brian@ucsd.edu.
-
- Archives of past issues of the Ham-Digital Digest are available
- (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
-
- We trust that readers are intelligent enough to realize that all text
- herein consists of personal comments and does not represent the official
- policies or positions of any party. Your mileage may vary. So there.
- ----------------------------------------------------------------------
-
- Date: 25 Aug 1994 23:37:22 GMT
- From: andyh@ucsd.edu
- Subject: HF -> internet gateways?
- To: ham-digital@ucsd.edu
-
- i'm looking for gateways which can receive pactor, amtor, gtor or
- rtty messages on HF and send them to an internet e-mail address.
-
- i'd be most grateful if anyone who knows of such things could
- email me details. i'll compile and post the results.
-
- thanks,
-
- andy howard <andyh@burn.ucsd.edu>
-
- ------------------------------
-
- Date: 25 Aug 1994 03:01:52 GMT
- From: news.sprintlink.net!sun.cais.com!news.cais.com!news@uunet.uu.net
- Subject: HF Packet (Mac vs PC)
- To: ham-digital@ucsd.edu
-
- Go ahead and get a Mac for this project,the software needed for what
- you want to do exists and is sold by the major TNC manufacturers.
- I heartdly recomend a Kam all mode TNC and Hostmaster for Mac from
- Kantronics.If you cant get a source or number for the manufacturer,send
- me some e-mail,I'll get it to you
-
- ------------------------------
-
- Date: Thu, 25 Aug 1994 05:40:07 GMT
- From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu
- Subject: HP100LX + Baycomm = Success?
- To: ham-digital@ucsd.edu
-
- J. Sherwood Williams (jwill@cabell.vcu.edu) wrote:
- :
- : Has anyone had any success using a Baycom type modem with the HP
- : 100LX palmtop? Before I go out and mess with it, it would be good
-
- The HP100LX works fine once the Baycom is powered by a 9 volt battery.
- Works even better with a PacComm HandiPacket and MSYS. With that it is a
- full forwarding BBS with all the goodies (node, etc.). In that way
- I can forward to the home BBS when I have mail to deliver and the home
- BBS can forward into me ... if I am there or not. We also ran it with a
- GTOR and Pactor port when running on a battery up in Algonquin Provintial
- Park. Worked great and saved all kinds of amp-hours as I didn't have to
- use the other laptop.
-
- I love it!
-
- 73,
- Steve
- ag807@cleveland.freenet.edu
- no8m@no8m.#neoh.oh.usa.na
-
- ------------------------------
-
- Date: 25 Aug 1994 13:46:06 GMT
- From: noc.near.net!transfer.stratus.com!abersoch.sw.stratus.com!northup@uunet.uu.net
- Subject: jnos trace question
- To: ham-digital@ucsd.edu
-
- I have just started using jnos110f and have been having a problem
- with having a trace show up on the screen. I can make it go to a
- file. What am I missing ?
-
- Bill
-
- --
- --
-
- Bill Northup PHONE: (508) 460-2085
- Stratus Computer Inc. INTERNET: northup@sw.stratus.com
- 55 Fairbanks Boulevard Packet: N1QPR@WA1PHY.#EMS.MA.USA.NA
- Marlboro, MA 01752 Amateur Radio: N1QPR
-
- ------------------------------
-
- Date: 25 Aug 1994 08:16:23 -0700
- From: nntp.crl.com!crl4.crl.com!not-for-mail@decwrl.dec.com
- Subject: jnos trace question
- To: ham-digital@ucsd.edu
-
- In article <33i7au$rr1@transfer.stratus.com>,
- northup@abersoch.sw.stratus.com (Bill Northup) wrote:
-
- > I have just started using jnos110f and have been having a problem
- > with having a trace show up on the screen. I can make it go to a
- > file. What am I missing ?
-
- An <F9> key.
-
- After you have entered "Trace xxxx" <ENTER> (where "xxxx" is the
- representation of the type of trace you wish), mash the <F9> key to
- see the results.
-
- You can tell if you mashed the key hard enough by observing the upper
- left corner of the CRT (3rd line down). It will change from "Command"
- to "Trace". Mashing <F9> again will toggle back to Command Mode.
-
- If you wish, you can use other F-keys to sequentially observe multiple
- active sessions; <F1> being session 1, <F2> being session 2, etc.
- Unfortunately, TRACE does not act like an independent session, and the
- TRACE screen will "freeze" if you are watching another session.
-
- Lou
-
- ------------------------Usual Disclaimers Apply-------------------------
- Internet: lgenco@crl.com Lou.Genco@LChance.sat.tx.us
- Ham Radio Packet: N5SGL @ K3WGF.#SAT.TX.USA tcp/ip: n5sgl@sat.ampr.org
- ------------------------------------------------------------------------
-
- ------------------------------
-
- Date: 25 Aug 1994 01:08:48 GMT
- From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!ix.netcom.com!netnews@network.ucsd.edu
- Subject: jnos w/enet card
- To: ham-digital@ucsd.edu
-
- I am running JNOS 1.10f and have installed gvc ethernet cards in my
- jnos pc and my other pc. The cards check out fine between the machines
- running the diagnostics. The supplied driver comforms to FTP specs. I
- have included the PACKET protocol in my config.h . THe attach works
- fine, but I cannot get jnos to recognize the packets I am sending to
- it. The trace on the port avails nothing. Any ideas or suggestions
- for debugging would greatly be appreciated, especially configuration
- options for jnos I may not have set correctly. Thanks.
- 73 de Bill Abernathy, kd5lu.
-
- ------------------------------
-
- Date: Thu, 25 Aug 1994 02:42:38 GMT
- From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!ulowell!simtel.coast.net!msdos-ann-request@network.ucsd.edu
- Subject: mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies
- To: ham-digital@ucsd.edu
-
- I have uploaded to the SimTel Software Repository (available by anonymous
- ftp from the primary mirror site OAK.Oakland.Edu and its mirrors):
-
- SimTel/msdos/packet/
- mlhacker.zip Zenith Minisport docs, hints, hacks & goodies
-
- mlhacker.zip is a compendium of newsletters about the Zenith Minisport
- laptop computer and its use as a packet radio host computer. Zenith
- offers only minimal and expensive support for this popular but
- discontinued 8086 compatible notebook computer. Newsletters contain
- technical notes, construction projects, operating hints, resources,
- architecture details and other related goodies. The Minisport Laptop
- Hacker series is the result of owning and repairing Minisports and
- donations from others on Internet and the Amateur Radio packet networks.
-
- Special requirements: None
-
- Changes: Compendium includes Minisport Laptop Hacker #1 - #22.
-
- FreeText. Uploaded by the author.
-
- Brian Mork
- bmork@opus-ovh.spk.wa.us
- ka9snf@ka7fvv.#ewa.wa.usa
- 6006-B Eaker, Fairchild, WA 99O11
- V:509-244-3764 D:509-244-9260
-
- ------------------------------
-
- Date: 25 Aug 1994 11:51:22 GMT
- From: news.cerf.net!gopher.sdsc.edu!news.tc.cornell.edu!travelers.mail.cornell.edu!news.kei.com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston@ihnp4.ucsd.edu
- Subject: Packet Routing with JNOS 110f
- To: ham-digital@ucsd.edu
-
- I want to use JNOS as a packet switch between an AX25 serial link and an
- ether net segment.
-
- With the autoexec.nos listed below, I can ping machines on the 1.0.0/24
- (ethernet) side of the net and I can ping machines on the 1.0.1/24
- (AX.25) side of the net. The problem I have is that if I try to ping
- say 1.0.0.45 from 1.0.1.99, the packets dont go anywhere. The default
- route on my AX.25 machine is set to:
-
- route add default sl1 1.0.0.99
-
- The way I figure it, 1.0.0.99 should see the ping for 1.0.0.45 from
- 1.0.1.99 and route ot from the AX.25 side out onto the ether net side
- but this isn't hapening.
-
- Is there something I'm not doing right?
-
- By the way, don't get upset about my IP numbers. None of these nets are
- connected to anything and just exist on an experimental test bed.
-
- ------------------------AUTOEXEC.NOS for 1.0.0.99------------
- ## ip setup
- ip address 1.0.0.99
- hostname dave.ards.dnd.ca.
-
- ## ax25 setup
- ax25 mycall dave
- ax25 bctext "ARDS testbed Daves Machine"
-
- ## attach interfaces
- attach asy 0x3f8 4 ax25 sl1 1025 768 9600
- ifconfig sl1 ipaddress 1.0.1.99
- ifconfig sl1 descr "AX25 Connection to Laptop"
-
- attach packet 60 lan1 100 1500
- ifconfig lan1 ipaddress 1.0.0.99
- ifconfig lan1 descr "Packet Connection to DLAEEM"
-
- ## Start Servers
- start ax25
- start ftp
- start telnet
-
- ## Routing
- route add 1.0.1/24 sl1
- route add 1.0.0/24 lan1
-
- ip hport sl1 on
- ip hport lan1 on
- ax25 hport sl1 on
-
- --
-
- |------------------------------------------------------------|
- | Captain Dave Mercer M.Eng., P.Eng. |
- | Directorate of Land Armament and |
- | Electronics Engineering and |
- | Maintenance 2-3-3 |
- | National Defence Headquarters |
- | Ottawa, Ontario, Canada |
- | K1A 0K2 |
- | |
- | Voice: (819) 997-9831 |
- | Fax: (819) 994-4246 |
- | EMail: mercer@dgs.dnd.ca |
- | HAM: VE3XMJ |
- |------------------------------------------------------------|
-
-
- -----BEGIN PGP PUBLIC KEY BLOCK-----
- Version: 2.3
-
- mQCNAiw7jJkAAAEEALpAIvULlA/xvrzuR30NcLZE0HCHyGm5QR4ej8xM6k3AcH3T
- Q3NkgV2FK5f8t/fBAhO1+ffa5K7F10B4hPqKkAASNlk1PIx9ty5oUgxAlZnfya4V
- ScNIx0x2h2f3roRjiZLfNYM2zkm26sZhFQjVJxyNnluJq/xVb45/LyY+p9flAAUR
- tCBEYXZpZCBNZXJjZXIgPG1lcmNlckBuY3MuZG5kLmNhPg==
- =0azF
- -----END PGP PUBLIC KEY BLOCK-----
-
- ------------------------------
-
- Date: Wed, 24 Aug 94 20:27:08 PDT
- From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!svc.portal.com!portal!cup.portal.com!lgm@network.ucsd.edu
- Subject: What SB for Digital modes?
- To: ham-digital@ucsd.edu
-
- all digital is on LSB on 20 meters
-
- ------------------------------
-
- Date: Thu, 25 Aug 1994 16:34:28 GMT
- From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!world!dts@network.ucsd.edu
- To: ham-digital@ucsd.edu
-
- References <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <CuzyoI.8tt@world.std.com>, <33i45b$oao@acorn.acorn.co.uk>.com
- Subject : Re: Looking for DXCluster software
-
- In article <33i45b$oao@acorn.acorn.co.uk>,
- Adrian Godwin <agodwin@acorn.co.uk> wrote:
- >In article <CuzyoI.8tt@world.std.com>,
- >Daniel T Senie <dts@world.std.com> wrote:
- >>
- >>How is the PacketCluster machine to know that the UI frame with a DX
- >>spot just got stomped by another station starting to transmit a frame?
- >>Packet radio does NOT run with Collision Detection in the way that
- >>Ethernet does. You cannot tell, when transmitting, that your frame
- >>has just gotten munched.
- >>
- >
- >It's not that difficult : most broadcast protocols work on a NAK-only
- >scheme - clients of the server respond only when they miss a packet,
- >and the server than retransmits it.
- >The method of detecting that missed packet varies, but a popular method
- >is to number the transmitted packets and complain when a hole appears in
- >the number sequence.
-
- Adrian, thanks for your comments, and this is exactly what I was trying
- to call out. There are certainly solutions such as numbered packets
- which can be implemented. Essentially what you're doing then is to
- create another protocol layered atop the broadcast mechanism. It's
- not that different from the multicast implementations. I was primarily
- pinting out that the "simple" solution that had been mentioned was
- not sufficient.
-
- >
- >This has some difficulties for a DX-Cluster style service : as I understand
- >it (I don't use DX Cluster) you expect transmissions at intervals, rather
- >than a continuous stream. Thus, you wouldn't know you missed one until
- >the next arrived - a second or an hour later. Regular empty packets, sent
- >just to ensure everyone was up to date, might be sufficent to fix this,
- >and there are more sophisticated schemes around to ensure this doesn't
- >itself become a bandwidth hog. These require that the server keep track
- >of its clients rather than doing pure broadcast, but that's no worse than
- >having multiple VCs.
-
- Exactly. The frequency of packets is an issue. It would be necessary to
- send out null packets every 30 seconds or so to ensure all stations
- received the broadcasts in a timely fashion. Even 30 seconds may be
- too long... At some point you really clog the channel with null packets
- placed there to ensure naks happen correctly when needed...
-
- >
- >However, I think you're correct to be concerned about low reliability of
- >packet systems - on typical terrestrial packet, the success rate is very
- >low. As a result, a protocol optimised for the assumption that most packets
- >get through (and don't require ACKing) might turn out disastrously wrong -
- >I think a successful broadcast scheme would require both a well-engineered
- >high-reliability transmission scheme (good paths, no hidden terminals etc)
- >and a protocol that gets no worse than multiple-VCs even in poor conditions.
- >It might work pretty well with a full-duplex repeater and extremely well
- >with a polled hub (where a small amount of reverse traffic can be effectively
- >free by imposing no additional overhead).
- >
- >I don't know how closely satellite operation approaches this (do they split
- >uplink and downlink packet frequencies ? ). I'd be interested to hear from
- >users of the Pacsat broadcast system and even more interested to hear from
- >anyone who has experimented with a terrestrial broadcast setup.
-
- Dan
- --
- ---------------------------------------------------------------
- Daniel Senie Internet: dts@world.std.com
- Daniel Senie Consulting n1jeb@world.std.com
- 508-779-0439 Compuserve: 74176,1347
-
- ------------------------------
-
- Date: 25 Aug 1994 13:51:55 +0100
- From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!EU.net!uknet!acorn!not-for-mail@network.ucsd.edu
- To: ham-digital@ucsd.edu
-
- References <3306v8$jbi@vixen.cso.uiuc.edu>, <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <CuzyoI.8tt@world.std.com>
- Subject : Re: Looking for DXCluster software
-
- In article <CuzyoI.8tt@world.std.com>,
- Daniel T Senie <dts@world.std.com> wrote:
- >
- >How is the PacketCluster machine to know that the UI frame with a DX
- >spot just got stomped by another station starting to transmit a frame?
- >Packet radio does NOT run with Collision Detection in the way that
- >Ethernet does. You cannot tell, when transmitting, that your frame
- >has just gotten munched.
- >
-
- It's not that difficult : most broadcast protocols work on a NAK-only
- scheme - clients of the server respond only when they miss a packet,
- and the server than retransmits it.
- The method of detecting that missed packet varies, but a popular method
- is to number the transmitted packets and complain when a hole appears in
- the number sequence.
-
- This has some difficulties for a DX-Cluster style service : as I understand
- it (I don't use DX Cluster) you expect transmissions at intervals, rather
- than a continuous stream. Thus, you wouldn't know you missed one until
- the next arrived - a second or an hour later. Regular empty packets, sent
- just to ensure everyone was up to date, might be sufficent to fix this,
- and there are more sophisticated schemes around to ensure this doesn't
- itself become a bandwidth hog. These require that the server keep track
- of its clients rather than doing pure broadcast, but that's no worse than
- having multiple VCs.
-
- However, I think you're correct to be concerned about low reliability of
- packet systems - on typical terrestrial packet, the success rate is very
- low. As a result, a protocol optimised for the assumption that most packets
- get through (and don't require ACKing) might turn out disastrously wrong -
- I think a successful broadcast scheme would require both a well-engineered
- high-reliability transmission scheme (good paths, no hidden terminals etc)
- and a protocol that gets no worse than multiple-VCs even in poor conditions.
- It might work pretty well with a full-duplex repeater and extremely well
- with a polled hub (where a small amount of reverse traffic can be effectively
- free by imposing no additional overhead).
-
- I don't know how closely satellite operation approaches this (do they split
- uplink and downlink packet frequencies ? ). I'd be interested to hear from
- users of the Pacsat broadcast system and even more interested to hear from
- anyone who has experimented with a terrestrial broadcast setup.
-
- -adrian
-
- ------------------------------
-
- End of Ham-Digital Digest V94 #285
- ******************************
-